@ysbaddaden can you please review @dlukez PR (#714) and work together with him to ensure we have one valid option?

Seems like your tests are a bit more elegant but @dlukez had a couple that test actual expressions, not sure if that's needed though.

Yeah this test setup is way better!

Also, I think this PR allows for dynamically changing the attribute, whereas in mine the autoscroll expression is cached when linking occurs (and $eval'd later).

I am ft

Thanks
Josh Kurz (mobile) c

----- Reply message -----
From: "Daniel Zimmermann" [email protected]
To: "angular-ui/ui-router" [email protected]
Subject: [ui-router] feat(uiView) autoscroll attribute (#715)
Date: Mon, Dec 23, 2013 23:41
Also, I think this PR allows for dynamically changing the attribute, whereas in mine the autoscroll expression is cached when linking occurs (and $eval'd later).

—
Reply to this email directly or view it on GitHub.

Stupid me, I didn't check the current PR and duplicated work. I reviewed #714 and made some changes.

I'm caching the expression too, since it's not supposed to be changed once the template is compiled (only the expression should change).

sry about the spam email. My phone messes up sometimes and does crazy
things in my pocket.

Thanks
Josh Kurz

On Tue, Dec 24, 2013 at 9:13 AM, Julien Portalier
[email protected]:

Stupid me, I didn't check the current PR and duplicated work. I reviewed
#714 #714 and made some
changes.

I'm caching the expression too, since it's not supposed to be changed once
the template is compiled (only the expression should change).

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/715#issuecomment-31172845
.

Josh Kurz
www.atlantacarlocksmith.com http://www.atlantacarlocksmith.com

Hey guys, first of all, thanks for your efforts here. However, after further consideration, I don't think the ngInclude approach (i.e. just using $anchorScroll) fits well with uiView. IMO $anchorScroll is unidimensional, whereas uiViews exist in a hierarchy and there can be many on the page at one time (there may even be many in a single state).

Rather than simply make autoscroll scroll to the current anchor, a much more intuitive interface would be to scroll to the actual uiView on which autoscroll is declared (and evaluates truthy). This gives UI designers much more power and flexibility, with the simplicity of not needing anchors in every URL.

Therefore I see two options: (1) we can forego this PR in favor of a new implementation, or (2) we can merge this now with the understanding that the implementation will change in a BC-breaking way.

Thoughts?

Yeah, when looking at this I didn't feel like $anchorScroll really seemed to fit either. Something was off. I think the first of those options is the way to go.

Could it be as simple replacing $anchorScroll with element[0].scrollIntoView()?
http://plnkr.co/edit/QHTUaC?p=info

Might need a $timeout (any other way?) to wait until the browser's rendered so it knows how much of the element to show: http://plnkr.co/edit/21iV1j?p=info
For me, the $timeout version scrolls the whole list into view rather than the top half or so as in the previous link.

-- edit --
Put "true" (no quotes) or a similar truthy expression in the box to make it autoscroll

I created this pull request because I didn't have any control over the scroll for a given uiView: sometimes we don't want any scroll at all (eg: scrolling into view a position:fixed element leads to an unpredictable behavior). So, I'd like the autoscroll attribute to happen.

Now I'm fine with using Element.scrollIntoView inside a $timeout instead of $anchorScroll. Maybe have a $uiViewScroll provider, so developers can customize the behavior further (eg: use $anchorScroll again)?

@ysbaddaden Awesome! This looks perfect. Thanks a lot for the extra work.

Hello everyone,

It's great to know that we can now control the scrolling on ui-view update! 👍

However I have the following two questions:

Is there a way know to which view the viewport will scroll when entering a state with multiple named states or nested states?

Secondly, if I want to do the scrolling all by myself (i.e. do anchorScroll() manually on stateChangeComplete only under certain conditions), do I have to add autoscroll="false" to all my ui-views?

Is there a way know to which view the viewport will scroll when entering a state with multiple named states or nested states?

@MrOrz Since autoscroll is an expression that gets evaluated, you can determine which ui-view gets scrolled to however you like. However, AFAIK this would be restricted to the list of ui-views that change content when the state changes.

Secondly, if I want to do the scrolling all by myself (i.e. do anchorScroll() manually on stateChangeComplete only under certain conditions), do I have to add autoscroll="false" to all my ui-views?

Currently the default behavior is maintained, such that $anchorScroll() by default will still happen. However, there's currently no way to disable all scrolling (including $anchorScroll()) across the board. Perhaps we could add a flag method to $ViewScrollProvider in a subsequent enhancement.

The actual scroll is now a provider and can be configured to use either the old or new behavior; it may also be overriden using a decorator:

$provide.decorator('$uiViewScroll', function ($delegate) {
  return function (uiViewElement) {
    console.log("Manually scroll to:", uiViewElement);
  };
});

Would we ever want to be able to override a ui-view's autoscrolling behavior when calling $state.go() or using a ui-sref?

I can think of cases where I'd want to control a view's autoscrolling behavior, depending upon the way that the view was activated.

Im a bit confused by all of this...

When I use data-autoscroll="true" my page jumps up and down horribly, when I dont use the attribute at all, my pages viewport isn't at the top.

What is the correct way to have a page load into the viewport starting at the top of the content?

@blowsie did you solve this issue? I have the same question.

I ended up implementing my own fix, There has been a few updates since i reported the issue, I haven't had time to see if the issue still occurs in the ui-router code